Software for most applications is created by software specialists, rather than by specialists in the respective applications which the software is ultimately used to perform. Two reasons for this are that programming tools are both difficult to learn and to use, thus creating heavy educational and intellectual burdens for prospective computer programmers. Today, many software users begrudgingly accept that software development is too difficult and too expensive to undertake unless one specializes in it. Further, paralleling this software creation problem has been a software maintenance problem, where often even the simplest of software modifications to accommodate a change in business practices is typically too expensive and time consuming to be practical.
Most computer users purchase packaged software, rather than develop it themselves. The vendors that supply such packaged software are generally "middle people," obtaining their stock of merchandise from "software houses" which employ teams of specialist programers, who actually write and debug the software "code." To benefit from economics of scale, consistent with standard marketing practice in most industries, the parties along this software chain of supply strive to create or stock generic sets of programs, and code modules for creating programs, to sell to the broadest possible customer base while incurring the lowest possible operating expenses, of which customer service is generally acknowledged to be one of the highest.
For software users the result of the current software creation and supply system has been pressure to standardize their computerized business practices around what is available in generic software packages, or what is easily built from generic code modules. In this environment, specialized software tasks such as one-off "what if" market analysis and filling specialized customer requests that require unusual data analysis typically have strong expense and time disincentives.
Of course, there have been attempts to change this system. Perceiving lucrative opportunities, a marketing approach by some software houses to the problem has been specialization in providing software "tools" (i.e., the software used to create software). Another impetus for change has been reducing the time to completion and the complexity of very large computer projects. Of particular note here are academic and government groups which have adopted a "we are big enough that we can do anything" organizational approach, and have attempted to either create better software tools themselves, or to pseudo-legislate better tools into existence (often by imposing "procurement" standards on their suppliers). Unfortunately, almost all of these software improvement efforts have focused on supplying tools more suitable for existing software specialists, than for end software users. The previously mentioned code modules are usually examples of this. Further, such organizational efforts to date are generally conceded to be marginal successes, at best. Examples include once greatly hailed programming advances such as structured programming, in the 1970's, and object-oriented programming, in the 1980's. Third generation languages from these eras, such as C and C++, are not being replaced by later generations. Fourth generation languages today remain something inflicted on university Computer Science majors for one semester, and the only major fifth generation language development project, to date, has become an embarrassment to the government that funded it. The ultimate critics, however, are software end users, and in their general perception even notable successes like spreadsheets and structured query language ("SQL") data bases remain too expensive, too inflexible, and too unmodifiable, when all the hardware, software, and personnel factors are summed up.
Software users want tools which they can use to easily write and modify software themselves. Complex programming languages, regardless of how powerful they are, are simply not acceptable. Users want the mathematical power of spreadsheets and the data access power of SQL, without the generally high "learning curve" that even these software tools often carry today.